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Abstract 


CMMI  “roadmaps” — which  are  a  goal-driven  approach  to  selecting  and  deploying  relevant 
process  areas  from  the  CMMI -DEV  model — can  provide  guidance  and  focus  for  effective  CMMI 
adoption.  The  Dutch  Software  Process  Improvement  (SPIder)  network  convened  a  workshop  in 
November  2006  to  develop  several  CMMI  roadmaps  for  the  continuous  representation,  each  with 
a  specific  set  of  improvement  goals.  These  roadmaps  combine  the  strengths  of  both  the  staged  and 
the  continuous  representations. 
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1  Introduction 


1.1  The  Rationale  for  Roadmaps 

CMMI  uses  two  representations:  staged  and  continuous.  The  staged  representation  is  the  most 
used  representation,  although  the  continuous  representation  is  commonly  perceived  to  be  a  more 
flexible  option.  Often,  potential  CMMI  users  do  not  select  the  continuous  representation  because 
they  find  it  difficult  to  pick  “the  right  set  and  order”  of  process  areas  for  their  situation.  Potential 
users  may  then  choose  the  staged  representation  because  they  don’t  know  where  to  start  in  the 
continuous  representation. 

The  staged  representation  could  be  considered  a  comprehensive  roadmap  for  the  continuous  rep¬ 
resentation.  This  approach  fits  those  organizations  that  want  to  systematically  improve  the  capa¬ 
bility  of  their  development  activities.  The  order  of  process  areas  (the  selection  of  process  areas 
that  belong  to  a  certain  maturity  level)  is  mainly  determined  by  historical  analysis  of  process 
problems  in  development  organizations.  Project  management  and  commitment  problems  have 
typically  prevented  an  efficacious  development  from  taking  place — which  explains  why  maturity 
level  2  focuses  on  project-management-related  process  areas.  Once  these  problems  were  resolved, 
companies  needed  to  achieve  economies  of  scale  and  align  their  processes  for  all  projects  at  ma¬ 
turity  level  3. 

However,  sometimes  this  approach  is  not  the  most  beneficial.  Organizations  may  have  project 
management  that  functions  reasonably  well,  but  might  still  face  many  product  defects.  Other  or¬ 
ganizations  may  not  develop  software,  hardware,  or  systems  themselves,  but  integrate  compo¬ 
nents  from  external  suppliers  instead.  For  these  (and  other)  situations,  the  continuous  representa¬ 
tion  offers  the  possibility  of  designing  a  customized  roadmap  as  an  alternative  to  the  staged 
representation.  To  support  companies  in  their  selection  of  an  appropriate  sequence  of  process 
areas,  we  have  developed  several  roadmaps  for  the  continuous  representation,  each  addressing  a 
specific  set  of  improvement  goals.  These  roadmaps  combine  the  strengths  of  both  the  staged  and 
the  continuous  representations. 

1.2  The  History  of  Roadmaps 

The  first  idea — ^that  there  are  different  roadmaps  within  the  continuous  representation — arose  dur¬ 
ing  a  management  workshop  at  the  start  of  a  CMMI  implementation  activity.  This  particular  man¬ 
agement  team  had  difficulties  in  deciding  which  process  areas  to  implement  first.  The  consultant 
who  facilitated  this  workshop  asked,  “What  do  you  want  to  improve  first:  project  quality,  product 
quality,  or  process  quality?”  Everybody  agreed  on  process  quality. 

This  approach  was  discussed  with  a  fellow  CMMI  expert,  and  this  discussion  led  to  the  publica¬ 
tion  of  an  article  about  the  concept  of  roadmaps  in  a  leading  IT  journal  in  the  Netherlands  [Can- 
negieter  2006a],  as  well  as  a  keynote  presentation  at  the  PROFES  International  Conference  on 
Product  Focused  Process  Improvement  [Cannegieter  2006b].  Other  CMMI  consultants  and  ex¬ 
perts  had  a  positive  reaction — many  were  interested  and  saw  this  concept  as  a  contribution  to  the 
existing  CMMI  Product  Suite. 
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To  further  elaborate  on  the  roadmaps  concept  and  to  increase  the  support  for  roadmaps,  the  au¬ 
thors  organized  a  workshop  on  15  November  2006  in  cooperation  with  the  Dutch  SPI  network 
(SPIder).  Thirty-five  CMMI  practitioners  from  The  Netherlands  and  Belgium  attended  this  work¬ 
shop.  In  small  groups,  they  developed  the  roadmaps  described  in  this  report.  The  attendees  of  this 
workshop  are  listed  in  the  appendix. 

The  outcomes  of  this  workshop  led  to  this  technical  note.  It  has  been  reviewed  by  the  workshop 
attendees  and  the  SEI,  whose  review  led  to  further  refinements.  This  technical  note  is  a  contribu¬ 
tion  of  the  Dutch  SPI  community  to  the  international  SPI  community. 
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2  Use  of  the  Roadmaps 


2.1  Roadmaps  in  an  Improvement  Project 

The  roadmaps  in  this  report  are  primarily  intended  for  organizations  that  are  starting  a  CMMI  for 
Development  implementation,  deciding  to  use  the  continuous  representation,  and  needing  help  in 
deciding  what  process  areas  to  implement  first. 

An  improvement  project  starts  with  the  recognition  by  the  management  of  an  organization  that 
improvements  are  needed.  These  reasons  need  to  be  clear,  understood,  and  widely  accepted  within 
the  organization.  In  the  IDEAL  model,  this  phase  is  described  as  the  Initiate  phase. 

To  achieve  a  shared  understanding  of  the  current  situation,  an  analysis  can  help.  A  CMMI  ap¬ 
praisal  is  one  way  to  analyze  the  current  situation,  but  the  use  of  an  appraisal  implies  the  selection 
and  use  of  a  particular  CMMI  constellation,  which  may  be  premature  for  some  organizations. 
Other  ways  to  analyze  the  current  situation  include  evaluations  of  projects  or  processes,  customer 
satisfaction  investigations,  causal  analysis  of  defects,  benchmarks,  or  audits.  In  the  IDEAL  model, 
this  phase  is  described  as  the  Diagnose  phase. 

After  the  analysis  of  the  current  situation,  the  goals  of  the  improvement  project  and  the  problems 
that  have  to  be  solved  must  be  clear,  understood,  and  widely  accepted.  If  the  goals  fall  within  the 
scope  of  a  CMMI  constellation,  that  constellation  can  be  used  as  a  reference  model  for  the  im¬ 
provement  project.  At  this  point,  the  organization  needs  to  select  which  representation  to  use — a 
choice  that  is  determined  by  business,  cultural,  and  legacy  factors  [SEI  2006]. 

When  an  organization  decides  to  use  the  continuous  representation,  it  needs  to  determine  which 
process  areas  to  implement  first.  To  achieve  this  goal,  one  needs  to  understand  the  architecture  of 
CMMI,  the  content  of  the  process  areas,  and  the  relationships  among  the  process  areas,  which  can 
be  difficult  for  organizations  that  have  no  experience  with  CMMI.  In  practice,  this  can  lead  to 
three  situations: 

1 .  An  experienced  consultant  advises  an  organization  about  the  implementation  sequence.  One 
drawback  to  this  is  a  lack  of  ownership  for  this  decision  within  the  organization  itself  and  a 
dependency  on  the  consultant. 

2.  An  improvement  team  from  the  organization  studies  the  CMMI  for  Development  model  (or 
the  CMMI  for  Acquisition  model  or  the  CMMI  for  Services  model)  and  its  process  areas  in 
detail.  One  advantage  is  that  the  organization  develops  a  better  understanding  of  CMMI.  One 
drawback,  however,  is  that  this  process  takes  a  lot  of  time,  which  could  instead  be  spent  on 
improving  processes.  Another  possible  drawback  is  that  the  choices  made  may  not  fit  the 
goals  and  problems  of  the  organization. 

3.  The  organization  selects  the  Staged  representation.  One  drawback  of  this  approach  is  that  the 
selected  process  areas  may  not  represent  the  most  direct  approach  to  addressing  the  im¬ 
provement  goals. 

CMMI  model  roadmaps  are  tools  to  aid  organizations  that  want  to  use  the  continuous  representa¬ 
tion.  The  roadmaps  help  those  organizations  select  which  process  areas  to  implement  first,  based 
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on  the  improvement  goals  and  problems  that  the  organization  wants  to  solve.  At  the  same  time, 
organizations  that  choose  to  use  roadmaps  can  be  more  confident  that  they  have  selected  an  ap¬ 
propriate  set  of  process  areas  to  address  their  initial  needs. 

The  focus  of  this  report  will  also  be  on  CMMI  for  Development,  though  analogous  roadmaps 
could  be  developed  for  the  other  constellations. 

Five  roadmaps  are  recognized  at  this  point  in  time: 


Project  Roadmap  For  organizations  with  project  management-related  goals  or  busi¬ 

ness  problems 

Product  Roadmap  For  organizations  with  product-related  goals  (e.g.,  for  improved 

product  quality)  or  business  problems 


Product  Integration  For  organizations  with  product-assembling  goals  or  business 

Roadmap  problems.  Applicable  when  the  primary  challenge  for  projects  is 

correctly  integrating  software  componenfs,  hardware  components, 
or  both  software  and  hardware  components 


Process  Roadmap 


For  organizations  with  process  management-related  goals  or 
business  problems 


Measurement  Roadmap  For  organizations  with  measurement -related  goals  or  business 

problems 


Each  roadmap  contains  a  limited  set  of  four  to  eight  process  areas,  which  limits  the  scope  and  du¬ 
ration  of  the  first  improvement  cycle(s)  and  helps  organizations  to  focus  their  improvement  activi¬ 
ties  on  the  critical  few  process  areas  that  are  most  likely  to  provide  direct  benefit  to  their  situation. 
Since  each  organization  is  unique,  the  improvement  goals  and  problems  to  solve  first  are  different 
for  each  organization. 

After  finishing  ifs  implemenfafion  of  a  roadmap,  the  organization  will  generally  have  enough  ex¬ 
perience  with  process  improvement  in  general  and  with  CMMI  in  particular  to  define  the  next 
steps  themselves.  Flowever,  hints  are  given  to  suggest  likely  follow-on  process  areas. 

Figure  1  provides  an  overview  of  how  the  roadmaps  can  be  used. 


4  I  CMU/SEI-2008-TN-010 


Figure  1:  Using  the  Roadmaps 

2.2  Structure  of  a  Roadmap 

Every  roadmap  has  the  same  basic  structure. 

The  first  element  of  a  roadmap  is  its  purpose.  The  purpose  characterizes  the  typical  improvement 
goals  addressed  by  this  roadmap  and  the  typical  set  of  problems  being  solved. 

The  second  element  of  a  roadmap  is  its  potential  users.  Some  roadmaps  are  specifically  applicable 
to  certain  types  of  organizations,  and  if  this  is  the  case,  the  applicable  types  of  organizations  are 
stated. 

The  third  element  of  a  roadmap  presents  the  set  of  process  areas  that  belong  to  that  particular 
roadmap,  as  every  roadmap  contains  a  limited  number  of  process  areas.  The  rationale  is  that  the 
first  step  in  a  process  improvement  project  should  never  be  too  big.  Process  and  Product  Quality 
Assurance  (PPQA)  is  almost  always  one  of  the  included  process  areas,  because  without  this 
process  area,  an  organization  can  never  be  certain  that  a  process  is  actually  in  use  by  the  organiza¬ 
tion.  PPQA  may  also  be  useful  in  identifying  shortcomings  in  a  new  (or  refined)  process’s  defini¬ 
tion,  deployment,  or  implementation. 

The  next  element,  rationale  for  inclusion  or  exclusion  of process  areas,  describes  the  motivation 
for  selecting  a  particular  set  of  process  areas. 

The  last  element  in  the  roadmap  stmcture  is  possible  next  steps.  The  roadmaps  contain  certain 
process  areas,  and  after  the  first  improvement  cycle,  an  organization  can  identify  its  next  im¬ 
provement  path  by  selecting  another  roadmap  or  by  identifying  its  own  additional  set  of  process 
areas.  In  this  section,  some  possible  next  steps  are  suggested. 
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3  Project  Roadmap 


3.1  Purpose 

The  purpose  of  the  Project  roadmap  is  to  establish  control  of  projects.  Organizations  choosing  the 
Project  roadmap  typically  want  to 

•  be  sure  that  each  project  meets  its  requirements 

•  improve  the  estimation  of  time  and  effort  on  projects 

•  improve  the  planning  of  projects 

•  improve  the  involvement  of  relevant  stakeholders 

•  improve  the  monitoring  and  control  of  projects 

This  roadmap  is  meant  for  organizations  that  are  having  problems  such  as 

•  poor  planning  of  proj ects 

•  no  clear  scope  and  requirements  for  projects 

•  limited  involvement  of  relevant  stakeholders  in  projects 

•  limited  insight  into  the  progress  of  projects 

•  projects  that  suffer  continuous  scope  creep,  budget  overrans,  or  delayed  end-dates 

3.2  Potential  Users 

This  roadmap  is  used  by  organizations  whose  business  is  generally  carried  out  within  projects. 
The  success  of  these  organizations  depends  heavily  on  their  ability  to  control  projects.  Examples 
of  such  organizations  are 

•  a  software  house  that  carries  out  projects  for  customers 

•  a  software  department  of  an  organization  that  consists  of  projects  such  as  developing  soft¬ 
ware  for  in-house  systems 

3.3  Process  Areas 

To  achieve  the  goals  and  resolve  the  problems  described  above,  the  following  process  areas 
should  be  implemented. 

Project  Planning 

This  process  area  will  help  establish  and  maintain  plans  that  define  project  activities. 

Project  Monitoring  &  Control 

This  process  area  will  help  provide  an  understanding  of  a  project’s  progress  so  that  appropriate 
corrective  actions  can  be  taken  if  the  project’s  performance  deviates  significantly  from  the  plan. 

Requirements  Management 

This  process  area  will  help  manage  the  requirements  of  a  project’s  products  and  product  compo- 
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nents  and  identify  inconsistencies  between  those  requirements  and  the  project’s  plans  and  work 
products. 

Configuration  Management 

This  process  area  will  help  establish  and  maintain  the  integrity  of  selected  work  products  using 
configuration  identification,  configuration  control,  configuration  status  accounting,  and  configura¬ 
tion  audits. 

Process  and  Product  Quality  Assurance 

This  process  area  will  help  provide  staff  and  management  with  objective  insight  into  the  processes 
being  defined  and  deployed  and  associated  work  products. 

3.4  Rationale  for  Inclusion  or  Exclusion  of  Process  Areas 

These  five  process  areas  provide  for  the  basic  control  of  projects.  They  help  organizations  plan 
and  monitor  projects,  as  well  as  ensure  that  the  project  focuses  on  the  established  requirements. 
The  addition  of  the  Process  and  Product  Quality  Assurance  process  area  ensures  that  improved 
processes  are  used.  This  roadmap  overlaps  with  a  part  of  the  process  areas  of  'staged'  maturity 
level  2 — addressing  these  project  problems  first  has  certainly  been  the  main  motivation  of  the  au¬ 
thors  of  the  Software  CMM  and  of  CMMI. 

The  Integrated  Project  Management  and  Risk  Management  process  areas  are  not  included  in  the 
roadmap  because  they  are  only  effective  when  the  Project  Planning  and  Project  Monitoring  and 
Control  process  areas  are  implemented. 

The  Measurement  and  Analysis  process  area  can  be  a  good  addition  to  this  roadmap.  It  improves 
the  measurement  capability  of  the  organization,  which  can  help  to  improve  project  control.  It  is 
not  included  in  the  roadmap  because  the  first  priority  of  the  roadmap  is  to  achieve  basic  project 
control  (including  taking  corrective  action)  before  the  measurement  capability  is  improved. 

If  there  are  suppliers  to  a  project,  the  Supplier  Agreement  Management  process  area  can  be  a 
good  addition  to  this  roadmap. 

3.5  Possible  Next  Steps 

After  finishing  this  roadmap,  the  organization  may  choose  to  implement  one  of  the  other  road¬ 
maps,  depending  on  the  problems  and  goals  of  the  organization  at  that  time.  No  other  roadmap  is 
inherently  preferred  to  any  other  after  the  Project  roadmap  is  implemented. 

Another  possible  next  step  is  implementing  the  Measurement  and  Analysis  and  Supplier  Agree¬ 
ment  Management  process  areas.  When  implementing  these  process  areas,  the  organization  not 
only  improves  its  control  over  projects — it  also  reaches  maturity  level  2. 

It  is  also  possible  to  bring  project  control  to  a  higher  level  by  implementing  the  Integrated  Project 
Management  and  Risk  Management  process  areas.  Rather  than  addressing  these  process  areas  in  a 
way  that  introduces  completely  new  processes,  implementing  these  process  areas  should  instead 
result  in  refinements  to  the  definitions  of  the  processes  already  introduced  as  part  of  the  Project 
roadmap. 
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After  having  completed  the  Project  roadmap,  organizations  can  improve  their  measurement  capa¬ 
bilities  and  quantitatively  control  their  projects  further  by  first  implementing  the  Measurement 
and  Analysis  process  area  and  then  by  implementing,  with  care,  selected  practices  from  the  Quan¬ 
titative  Project  Management  process  area. 

Organizations  can  also  define  their  own  improvement  path  after  finishing  the  Project  roadmap  by 
choosing  process  areas  that  best  meet  their  improvement  goals  at  that  time.  Furthermore,  it  is  a 
good  option  to  further  improve  the  organization’s  implementation  of  the  process  areas  in  this 
roadmap  by  bringing  the  selected  process  areas  to  higher  capability  levels. 
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4  Product  Roadmap 


4.1  Purpose 

The  purpose  of  the  Product  roadmap  is  to  effectively  develop  products  that  meet  the  needs  of  cus¬ 
tomers  and  to  improve  product  quality.  Organizations  choosing  the  Product  roadmap  typically 
want  to 

•  improve  the  quality  of  their  products 

•  decrease  the  problems  with  products  after  release 

•  decrease  time  spent  on  building  products  by  decreasing  time  spent  on  unrealistic  or  un¬ 
wanted  requirements,  impractical  or  inferior  designs,  or  ineffective  implementations 

•  improve  customer  satisfaction 

This  roadmap  is  meant  for  organizations  having  problems  such  as 

•  dissatisfied  customers 

•  too  many  defects  in  delivered  products 

•  excessive  maintenance  costs 

•  finding  defects  in  development  projects  too  late  in  the  project  lifecycle 

•  insufficient  control  over  the  quality  of  products 

4.2  Potential  Users 

This  roadmap  could  be  used  by  organizations  that  make  products  where  poor  quality  results  in 
high  costs  or  dissatisfied  customers.  The  success  of  the  organizations  using  the  Product  roadmap 
is  determined  by  the  quality  of  the  products  made.  Examples  include 

•  organizations  that  develop  standard  products  that  are  used  by  different  customers  at  different 
locations 

•  organizations  that  develop  components  to  be  used  in  other  systems 

•  organizations  that  develop  systems  which,  if  the  systems  malfunction  during  operation,  have 
large  effects  on  the  customer,  human  life,  or  business  continuity  of  companies 

4.3  Process  Areas 

To  achieve  the  goals  and  resolve  the  problems  described  above,  the  following  process  areas 
should  be  implemented. 

Requirements  Development 

This  process  area  will  help  analyze  and  establish  customer,  product,  and  product  component  re¬ 
quirements. 
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Requirements  Management 

This  process  area  will  help  manage  the  requirements  associated  with  a  project’s  products  and 
product  components  and  identify  inconsistencies  between  the  requirements  and  the  project’s  plans 
and  work  products. 

Technical  Solution 

This  process  area  will  help  select,  design,  develop,  and  implement  solutions  to  requirements.  So¬ 
lutions,  designs,  and  implementations  encompass  products,  product  components,  and  product- 
related  life-cycle  processes  either  singly  or  in  combination  as  appropriate. 

Configuration  Management 

This  process  area  will  help  establish  and  maintain  the  integrity  of  selected  work  products  by  using 
configuration  identification,  configuration  control,  configuration  status  accounting,  and  configura¬ 
tion  audits. 

Verification 

This  process  area  will  help  ensure  that  selected  work  products  meet  specified  requirements. 
Process  and  Product  Quality  Assurance 

This  process  area  will  help  provide  staff  and  management  with  objective  insight  into  the  processes 
being  defined  and  deployed  and  associated  work  products. 

4.4  Rationale  for  Inclusion  or  Exclusion  of  Process  Areas 

These  six  process  areas  will  help  to  effectively  develop  products  and  improve  the  quality  of  prod¬ 
ucts.  They  help  organizations  develop  and  manage  requirements,  guard  the  integrity  of  work 
products,  and  make  sure  that  the  work  products  meet  all  requirements.  The  addition  of  the  Process 
and  Product  Quality  Assurance  process  area  ensures  that  improved  processes  are  used. 

The  Validation  process  area  is  initially  excluded  due  to  its  focus  on  building  the  right  product. 

The  Verification  process  area,  however,  is  considered  to  initially  be  more  important  for  successful 
product  development,  and  is  included  in  this  roadmap  accordingly. 

4.5  Possible  Next  Steps 

After  finishing  the  roadmap,  the  organization  can,  depending  on  the  problems  and  goals  of  the 
organization  at  that  time,  implement  one  of  these  roadmaps:  Project,  Process,  or  Measurement. 

Implementing  the  Product  Integration  roadmap  may  not  often  be  the  best,  first,  or  next  choice,  as 
the  Product  Integration  roadmap  is  aimed  at  organizations  that  need  a  deeper  focus  on  effective 
product  integration,  whereas  the  Product  roadmap  is  aimed  at  organizations  with  a  focus  on 
broader  aspects  of  development. 

Organizations  that  have  finished  the  Product  roadmap  can  also  deepen  and  improve  their  control 
over  the  development  process  by  implementing  the  Product  Integration  and  Validation  process 
areas.  In  particular,  the  organization  may  choose  the  Validation  process  area  when  there  is  a  high 
risk  of  building  either  unusable  products  or  the  wrong  products.  Implementing  an  Agile  approach 
(e.g.,  SCRUM  and  XP;  or  FDD)  may  also  help  with  these  concerns,  when  access  to  and  commit- 
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ment  from  customers  is  adequate,  and  when  other  project  factors  (e.g.,  an  experienced  team)  favor 
an  Agile  approach. 

Organizations  can  also  define  their  own  improvement  path  after  finishing  the  Product  roadmap  by 
choosing  those  process  areas  that  best  meet  their  improvement  goals  at  that  time.  Furthermore,  it 
is  a  good  option  to  further  improve  the  process  areas  in  this  roadmap  by  bringing  the  selected 
process  areas  to  higher  capability  levels. 
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5  Product  Integration  Roadmap 


5.1  Purpose 

The  purpose  of  the  Product  Integration  roadmap  is  to  gain  control  of  the  integration  process  and 
ensure  that  the  overall  system  meets  its  requirements.  These  organizations  do  not  typically  devel¬ 
op  the  components  themselves;  they  instead  assemble  a  system  from  acquired  components.  Or¬ 
ganizations  choosing  the  Product  Integration  roadmap  typically  want  to 

•  gain  control  over  the  integration  process,  integration  sequence,  or  the  quality  of  supplied 
products 

•  become  confident  that  individual  components  can  be  integrated  into  a  cohesive  system 

•  ensure  that  the  overall  system  (the  assembly)  achieves  its  quality  goals 

•  deliver  products  that  fit  the  market  needs 

•  select  well-qualified  suppliers 

This  roadmap  is  meant  for  organizations  having  problems  such  as 

•  bad  coordination  and  cooperation  between  the  various  suppliers 

•  no  control  over  the  quality  delivered  by  suppliers  of  work  products 

•  no  control  over  the  integration  process 

•  no  insight  into  the  extent  to  which  the  product  meets  the  user  needs  in  its  intended  environ¬ 
ment 

5.2  Potential  Users 

The  Product  Integration  roadmap  is  intended  for  those  organizations  that  do  not  perform  the  core 
development  tasks  (design,  programming,  unit  test,  etc.)  for  the  main  parts  of  the  system,  but  in¬ 
tegrate  sub-products  and  components  from  other  companies.  These  organizations  are  often  called 
system  integrators.  The  main  tasks  for  these  organizations  are  to 

•  specify  the  requirements  for  each  supplier 

•  define  the  overall  system  architecture,  including  system  interfaces  as  most  important  topic 

•  assemble  components  from  suppliers 

•  make  sure  the  total  systems  functions  in  accordance  to  the  requirements 

•  perform  program  or  portfolio  management  over  different  development  projects 

•  ensure  that  the  acquired  components  are  of  sufficient  quality  before  they  are  delivered 

5.3  Process  Areas 

To  achieve  the  goals  and  resolve  the  problems  described  above,  the  following  process  areas 
should  be  implemented. 
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Requirements  Development 

This  process  area  will  help  analyze  customer,  product,  and  product  component  requirements. 
Configuration  Management 

This  process  area  will  help  establish  and  maintain  the  integrity  of  work  products  (e.g.,  those  of  the 
project  itself  and  supplier  deliverables)  using  configuration  identification,  configuration  control, 
configuration  status  accounting,  and  configuration  audits. 

Technical  Solution 

This  process  area  will  help  design,  develop,  and  implement  solutions  to  requirements.  Solutions, 
designs,  and  implementations  encompass  products,  product  components,  and  product-related  life- 
cycle  processes  either  singly  or  in  combination  as  appropriate. 

Product  Integration 

This  process  area  will  help  assemble  the  product  from  the  product  components,  ensure  that  the 
product,  as  integrated,  functions  properly,  and  deliver  the  product. 

Supplier  Agreement  Management 

This  process  area  will  help  manage  the  acquisition  of  products  from  suppliers. 

Validation 

This  process  area  will  help  demonstrate  that  a  product  or  product  component  fulfills  its  intended 
use  when  placed  in  its  intended  environment. 

5.4  Rationale  for  Inclusion  or  Exclusion  of  Process  Areas 

These  six  process  areas  provide  basic  control  over  the  integration  process.  They  support  organiza¬ 
tions  in  developing  requirements,  properly  integrating  the  product,  managing  suppliers,  and  mak¬ 
ing  sure  that  the  end  product  fulfills  its  intended  use. 

The  Technical  Solution  process  area  has  been  included  here.  It  should  be  noted,  however,  that 
specific  goals  one  and  two  are  the  most  relevant  to  this  roadmap.  Specific  goal  three  is  mainly  the 
focus  of  product  component  developers,  who  are  external  companies  in  this  roadmap.  Additional¬ 
ly,  the  Acquisition  Technical  Management  process  area  (from  CMMI-ACQ)  might  be  included, 
depending  on  the  extent  to  which  the  project  needs  to  evaluate  the  technical  solutions  of  its  sup¬ 
pliers  and  their  implementation  prior  to  integration. 

The  Process  and  Product  Quality  Assurance  process  area  is  excluded,  due  to  this  roadmap’s  pri¬ 
mary  focus  on  managing  suppliers.  With  supplier  agreement  management,  system  integrators  as¬ 
sure  the  processes  of  their  suppliers.  Additionally,  organizations  should  include  the  Process  and 
Product  Quality  Assurance  process  area  if  the  process  area  is  important  (relative  to  other  risks)  to 
assure  their  own  processes. 

The  Requirements  Management  process  area  is  excluded,  due  to  this  roadmap’s  focus  on  integra¬ 
tion  instead  of  creation.  However,  if  the  risk  in  tracing  and  managing  the  allocation  of  require¬ 
ments  to  suppliers  is  high,  this  process  area  should  be  considered  for  inclusion  in  the  roadmap. 

The  Verification  process  area  is  included  to  help  ensure  that  selected  work  products  of  the  project 
meet  their  specified  requirements.  Because  product  components  are  acquired  from  suppliers  with- 


13  I  CMU/SEI-2008-TN-010 


in  product  integration,  verification  of  those  components  is  the  responsibility  of  the  suppliers. 
Through  the  Supplier  Agreement  Management  process  area  (and  the  Acquisition  Technical  Man¬ 
agement  process  area  of  CMMI-ACQ),  adequate  confidence  in  these  verifications  may  be 
achieved.  However,  the  organization  should  also  verify  its  own  work  products,  which  is  the  focus 
of  the  Verification  process  area. 

5.5  Possible  Next  Steps 

After  finishing  the  roadmap,  the  organization  can  implement  these  roadmaps:  Project,  Process,  or 
Measurement.  Implementing  the  Product  roadmap  would  not  be  the  first  choice,  as  this  roadmap 
is  aimed  at  organizations  with  more  of  an  internal  focus  on  development;  whereas  the  Product 
Integration  roadmap  is  aimed  at  organizations  that  need  to  more  deeply  focus  on  product  integra¬ 
tion. 

Organizations  can  also  define  their  own  improvement  path  after  finishing  the  Product  Integration 
roadmap  by  choosing  those  process  areas  that  best  meet  their  improvement  goals  at  that  time.  Fur¬ 
thermore,  it  is  a  good  option  to  further  improve  the  process  areas  in  this  roadmap  by  bringing  the 
selected  process  areas  to  higher  capability  levels. 

Finally,  as  already  stated,  it  may  be  appropriate  to  consider  the  Acquisition-specific  process  areas 
in  CMMI-ACQ  as  the  next  or  even  as  a  supplement  to  the  initial  roadmap.  The  Acquisition- 
specific  process  areas  may  be  preferred  as  an  initial  roadmap  to  the  roadmap  described  above  if 
the  organization  does  not  develop  or  integrate  product  components  (i.e.,  if  such  is  performed  by 
its  suppliers).  But  even  for  the  situations  described  in  sections  5.1  and  5.2,  as  already  stated,  the 
Acquisition-specific  process  areas  of  CMMI-ACQ  contain  additional  best  practices  for  managing 
the  project  and  effectively  managing  and  interfacing  with  suppliers.  As  the  community  gains  more 
experience  with  CMMI-ACQ,  we  will  be  in  a  better  position  to  know  how  best  to  tailor  this 
roadmap  to  meet  the  needs  of  different  organizational  situations. 
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6  Process  Roadmap 


6.1  Purpose 

The  purpose  of  the  Process  roadmap  is  to  develop  a  capability  to  define,  implement,  and  improve 
an  organization’s  set  of  processes.  This  can  create  a  basis  for  process  analysis  and  implementation 
of  other  process  areas  or  roadmaps.  Organizations  choosing  the  Process  roadmap  typically  want  to 

•  define  and  analyze  current  processes 

•  improve  processes  based  on  insight  into  the  processes  and  the  organization’s  needs  and 
priorities 

•  standardize  the  processes  of  the  organization 

•  define  a  basic  set  of  processes  as  a  basis  for  continuous  improvement 

•  establish  a  clear  set  of  requirements  for  the  quality  system  of  the  organization 

•  define  processes  that  are  compliant  with  applicable  regulations,  such  as  Sarbanes-Oxley, 

SAS  70,  ISO  9000,  or  other  regulations 

This  roadmap  is  meant  for  organizations  that  have  problems  such  as 

•  a  lack  of  clear  understanding  of  their  processes 

•  a  lack  of  control  over  their  processes 

•  difficulties  handing  work  over  to  other  or  new  employees 

•  limited  adoption  of  defined  processes 

•  employees  not  working  together  well  within  the  organization 

•  a  limited  ability  to  identify  problems  in  processes 

•  difficulty  in  improving  processes 

6.2  Potential  Users 

This  roadmap  is  used  by  organizations  using  complex  processes  due  to  the  size  or  complexity  of 
the  organization  and  its  projects  or  products.  The  success  of  organizations  that  use  the  Process 
roadmap  is  determined  by  the  degree  to  which  such  organizations  are  in  control  of  their  processes. 
Examples  of  these  organizations  are 

•  software  factories 

•  organizations  that  build  complex  systems  or  that  work  in  a  complex  environment 

•  organizations  where  many  different  disciplines  contribute  to  development 

•  organizations  where  different  suppliers  work  together 

•  organizations  where  competencies  and  the  knowledge  needed  to  perform  tasks  are  not  clear 
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6.3  Process  Areas 


To  achieve  the  goals  and  resolve  the  problems  described  above,  the  following  process  areas 
should  be  implemented. 

Organizational  Process  Focus 

This  process  area  will  help  plan,  implement,  and  deploy  organizational  process  improvements 
based  on  a  thorough  understanding  of  the  current  strengths  and  weaknesses  of  the  organization’s 
processes  and  process  assets. 

Organizational  Process  Definition 

This  process  area  will  help  establish  and  maintain  a  usable  set  of  organizational  process  assets  and 
work  environment  standards.  Organizations  in  which  many  different  disciplines  contribute  to  de¬ 
velopment  can  use  the  Integrated  Product  and  Process  Development  (IPPD)-specific  goal  of  this 
process  area.  It  helps  these  organizations  achieve  superior  integrated  team  performance. 

Measurement  and  Analysis 

This  process  area  will  help  develop  and  sustain  a  measurement  capability  that  is  used  to  support 
management  information  needs. 

Causal  Analysis  and  Resolution 

This  process  area  will  help  to  identify  causes  of  defects  and  other  problems  and  take  action  to 
prevent  them  from  occurring  in  the  future. 

Process  and  Product  Quality  Assurance 

This  process  area  will  help  provide  staff  and  management  with  objective  insight  into  the  processes 
being  defined  and  deployed  and  associated  work  products. 

6.4  Rationale  for  Inclusion  or  Exclusion  of  Process  Areas 

These  five  process  areas  provide  a  basis  for  defining,  implementing,  and  improving  processes  in 
the  organization.  Organizations  improve  their  insight  into  their  processes  and  insight  into  causes 
of  problems.  Process  measurements  provide  the  organization  with  the  deeper  understanding 
needed  to  improve  its  processes.  The  addition  of  Process  and  Product  Quality  Assurance  ensures 
that  improved  processes  are  used. 

The  Decision  Analysis  and  Resolution  process  area  would  be  a  good  addition  to  this  roadmap  as  it 
improves  the  evaluation  of  processes  and  the  way  the  organization  analyzes  and  makes  decisions; 
however,  it  has  not  been  included,  because  the  selected  process  areas  should  be  implemented  first. 

The  Organizational  Process  Performance  process  area  is  not  included  in  the  roadmap  because 
measurement  and  analysis  needs  to  be  implemented  first.  However,  implementing  this  process 
area,  as  well  as  the  Quantitative  Project  Management  process  area,  can  be  considered  a  next  step 
after  the  roadmap. 

6.5  Possible  Next  Steps 

The  next  step  after  finishing  this  roadmap  depends  on  the  organization’s  evaluation  of  its  process 
strengths  and  weaknesses.  If  decisions  are  being  made  that  require  greater  effectiveness,  objectivi- 
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ty,  control,  and  buy-in,  the  organization  can  implement  the  Decision  Analysis  and  Resolution 
process  area. 

Another  next  step  is  to  implement  one  of  the  other  roadmaps.  No  other  roadmap  is  inherently  pre¬ 
ferred  over  another  after  the  Process  roadmap  has  been  implemented. 

Organizations  can  also  define  their  own  improvement  path  after  finishing  the  Process  roadmap  by 
choosing  the  process  areas  that  best  meet  their  improvement  goals  at  that  time.  Furthermore,  it  is  a 
good  option  to  bring  the  selected  process  areas  to  higher  capability  levels,  and  therefore  improve 
the  process  areas  within  this  roadmap. 
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7  Measurement  Roadmap 


7.1  Purpose 

The  purpose  of  the  Measurement  roadmap  is  to  identify,  select,  and  measure  improvements  based 
on  quantitative  information.  This  roadmap  can  create  a  quantitative  basis  for  process  improvement 
and  makes  sure  organizations  select  their  improvements  based  on  quantitative  information.  Or¬ 
ganizations  choosing  the  Measurement  roadmap  typically  want  to 

•  measure  performance  improvements  quantitatively 

•  identify  and  select  improvements  based  on  quantitative  information 

•  be  able  to  quantitatively  demonstrate  the  results  of  process  improvements 

•  determine  the  most  important  key  performance  indicators  of  the  organization 

This  roadmap  is  meant  for  organizations  having  problems  such  as 

•  a  lack  of  quantitative  management  information  necessary  to  understand  the  performance  or 
the  organization 

•  identifying  and  selecting  improvement  activities  based  on  inadequate  quantitative  informa¬ 
tion 

•  a  management  team  that  remains  skeptical  of  the  contribution  of  process  improvement  to  the 
performance  of  the  organization 

•  a  need  to  use  quantitative  information  to  show  the  added  value  of  process  improvements 

•  excessive  measurement  system  error  (one  of  the  major  challenges  to  successfully  implement¬ 
ing  the  analyses  described  in  the  CMMI  high  maturity  practices) 

7.2  Potential  Users 

This  roadmap  is  used  by  organizations  that  want  to  begin  quantitatively  managing  their  improve¬ 
ment.  It  can  also  be  used  in  organizations  where  the  management  team  is  skeptical  about  the  add¬ 
ed  value  of  process  improvement.  (This  can  be  the  case  in  any  kind  of  organization.)  Furthermore, 
it  might  be  a  good  option  to  implement  the  measurement  roadmap  within  the  context  of  a  broader 
improvement  initiative,  like  Six  Sigma. 

7.3  Process  Areas 

To  achieve  the  goals  and  resolve  the  problems  described  above,  the  following  process  areas 
should  be  implemented. 

Measurement  and  Analysis 

This  process  area  will  help  develop  and  sustain  a  measurement  capability  that  is  used  to  support 
management  information  needs. 

Organizational  Process  Focus 

This  process  area  will  help  plan,  implement,  and  deploy  organizational  process  improvements 
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based  on  a  thorough  understanding  of  the  current  strengths  and  weaknesses  of  the  organization’s 
processes  and  process  assets. 

Decision  Analysis  &  Resolution 

This  process  area  will  help  analyze  possible  decisions  using  a  formal  process  that  evaluates  identi¬ 
fied  alternatives  against  established  criteria. 

Process  and  Product  Quality  Assurance 

This  process  area  will  help  provide  staff  and  management  with  objective  insight  into  the  processes 
being  defined  and  deployed  and  associated  work  products. 

7.4  Rationale  for  Inclusion  or  Exclusion  of  Process  Areas 

These  four  process  areas  provide  a  basis  for  defining,  implementing,  and  using  a  measurement 
and  decision-making  program  that  helps  organizations  to  improve  processes  based  on  quantitative 
information,  and  to  show  quantitatively  the  benefits  of  process  improvements. 

The  Causal  Analysis  &  Resolution  process  area  can  be  a  good  addition  to  this  roadmap.  With 
Causal  Analysis  &  Resolution,  organizations  select  improvements  based  not  only  on  quantitative 
information,  but  also  on  a  causal  analysis  of  selected  defects  and  problems. 

The  Organizational  Process  Performance  process  area  is  not  included  in  the  roadmap  because 
measurement  and  analysis  needs  to  be  implemented  and  in  place  for  some  time  first,  ft  can  be  a 
good  addition  to  this  roadmap  if  the  roadmap  has  been  implemented  for  some  time  (and  if  the 
Quantitative  Project  Management  process  area  is  also  implemented  concurrently). 

7.5  Possible  Next  Steps 

The  next  step  after  finishing  this  roadmap  depends  on  the  results  achieved.  Those  processes  that 
cause  the  most  failure  costs  or  show  the  most  variation  are  the  first  to  be  addressed. 

The  next  step  can  also  be  implementing  a  different  roadmap.  The  decision  as  to  which  roadmap  to 
select  depends  again  on  the  results  of  the  roadmap  implementation. 

Another  possible  next  step  is  improving  the  analysis  and  improvement  process  by  implementing 
the  Causal  Analysis  &  Resolution  process  area.  (However,  see  the  discussion  in  Section  7.4.) 

Organizations  can  also  define  their  own  improvement  path  after  finishing  the  Measurement  road¬ 
map  by  choosing  those  process  areas  that  best  meet  their  improvement  goals  at  that  time.  Fur¬ 
thermore,  it  is  a  good  option  to  further  improve  the  process  areas  in  this  roadmap  by  bringing  the 
selected  process  areas  to  higher  capability  levels. 
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Appendix  A  Attendees  of  the  SPIder  Workshop 


D.  Bierhuizen — Medis  Medical  Imaging  Systems 

L.  Braafhart — LogicaCMG  Nederland 

HJJ.  Cannegieter — SYSQA 
W.  den  Dekker — LogicaCMG  Nederland 
L.  Delmelk — LogicaCMG  Belgie 
A  J.  Donderman — Transfer  Solutions 
G.H.M.  Friedhoff— SYSQA 

L. L.  van  der  Giessen — ^ABN  AMRO 

M.  Haasnoot — Philips  Medical  Systems 

A.  Heijstek — Improvement  Focus 
C.C.  Ilgen— Ilgen  IT 

B.  de  Jong — ICT  NoviQ 

B.  Jurg— ICT  NoviQ 

G.  Leroy — Prosource 

J. R.  van  Mechelen — Compuware  Nederland 

M. P.H.M.  Mermans — Philips  Medical  Systems 

C.  Michielsen — ITIB 

N.  van  Mourik — SYSQA 

E. M.  Oostveen — ^Advanced 
M.H.M.  van  Os — Sogeti 

P.  Oudhuis — ^Rijkswaterstaat 

H.  Philip — Ordina 

K.  Rassels — Allshare 

G.A.S.M.  van  Schijndel — LogicaCMG  Nederland 
R.  van  Solingen — LogicaCMG  Nederland 
P.  Verheij — Ordina 

F. B.  van  Veen — Quality  House 

LJ.A.E.  Vis — Student  Vrije  Universiteit  Amsterdam 

E.  van  der  Vliet — LogicaCMG  Nederland 

P.  van  de  Vorst — Ordina 

J.  de  Vries — LogicaCMG  Nederland 

J.M.  Wijsman — Sogeti 

J.H.G.  Willemsen — Nederlandse  Spoorwegen 
A.PJJ.  Zopfi— KZA 


Additional  Reviewers: 

M.  Arendsen — SYSQA 
M.  Konrad— SEI 
M.  Muller — LogicaCMG 
J.  Zandhuis — SYSQA 
M.  Van  Tyne— SEI 
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